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METHOD AND SYSTEM FOR 
DETECTING A VULNERABILITY 
IN A NETWORK 



Inventors: 

John S, Flowers, Thomas C. Stracener 

RELATED APPLICATIONS 
This application claims the benefit of U.S. Provisional Application No. 
60/150,905, filed August 26, 1999, and incorporated herein by reference. 

FIELD OF THE INVENTION 
The present invention generally relates to network security, and more 
particularly, to a method and system for securing a network by detecting 
vulnerabilities in the network. 

BACKGROUND 

Computer networks are vulnerable to many threats that can inflict damage 
that can result in significant losses. These losses can stem from a number of sources 
including environmental hazards, hardware and software failure, user errors, or even 
malicious acts of others. A goal of network security is therefore to protect the 
confidentiality, integrity, and availability of information stored electronically in a 
network from these threatening sources. 
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In general, a network is a distributed computing environment with two or 
more hosts connected to a common framework for information exchange. 
Communication among networks and hosts within networks is frequently based on 
the OSI Model and is in accordance with a protocol, such as a TCP/IP protocol. 
5 Both the OSI Model and TCP/IP will be understood by one of ordinary skill in the 
art. 

With the TCP/IP protocol, data to be communicated is placed in data 
packets. FIG. 1 illustrates the structure of a standard IP packet, which will be 
familiar to one of ordinary skill in the art. The packet 1 1 1 includes a header 1 15 
10 and a data portion 1 10. The fields of the IP header are generally well-known in the 
art, and are described in detail inRFC-791, "Internet Protocol" Postel, September 
198 1 (available at www.ietf.org/rfc). Nonetheless, the fields are summarized here. 

The Version field 130 describes the version of the Internet protocol being 
used by the machine sending the data. Since header length is not constant, the 
1 5 Internet Header Length (IHL) 1 3 5 describes the number of the 3 2-bit words in the 
header 115. The IHL field 1 3 5 allows the receiving machine to calculate where the 
header 115 ends and the data 110 portion begins. 

The Type of Service field 140 provides an indication of the abstract 
parameters of the quality of service desired. For instance, various combinations of 
20 reliability and speed are available. 
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The Total Length field 145 is the length of the packet, measured in octets 
125, including the header 115 and data 110. An Identification field 150 is assigned 
by the sender to aid in assembling fragments of a packet. 

A three bit field of various control flags 155 is provided. The first bit is 
5 unused and always zero. The next bit DF is a "Don't fragment" bit: it allows 
fragmentation when set to 0 but indicates no fragmentation when set to 1 If DF is 
set to "1," it is an order to routers not to fragment the packet because the 
destination is incapable of putting the pieces back together again. The third bit MF 
is a "More Fragments" bit: it indicates the last fragment in series when set to 0; it 
10 indicates that there are more fragments in the series when set to 1 . 

The Fragment Offset field 160 indicates where in the entire datagram the 
fragment belongs. The fragment offset is measured in units of 8 octets (64 bits). 
The first fragment has offset zero. 

The Time to Live (TTL) field 1 65 indicates the maximum time the datagram 
15 1 1 1 is allowed to remain in the internet system. The Protocol field 1 70 indicates the 
next level protocol used in the data 110 portion of the packet. The Header 
Checksum 175 verifies the header only and is recomputed and verified at each point 
that the header 1 15 is processed. 

The Source address 180 and Destination address 185 are 32 bit fields used 
20 to indicate the source and destination of a packet. The Options field 190 varies and 
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may or may not appear in the packet 111. The Options field may also be padded 
to ensure that the header 115 ends on a 32 bit boundary. 

Several conventional resources are available to protect a network from 
information losses. For instance, firewalls are used to enforce a boundary between 
5 two or more networks to filter incoming traffic (generally from the Internet) 
according to a security policy. Still, firewalls are inadequate to fully protect a 
network since users may not always obtain access to a network through the Internet 
(for instance, a user could circumnavigate the firewall by using a modem 
connection). In addition to the many ways a network can be attacked externally, 
1 0 not all threats originate outside the firewall and can come from within the network. 
Further, firewalls themselves are subject to attack many of which can render the 
firewall ineffective. 

Therefore, networks need to rely on resources other than firewalls for 
network security. Such resources include vulnerability assessment tools. 
15 Vulnerability assessment tools perform examinations of a network to 

determine weaknesses in the network that might allow security violations. The 
results of a vulnerability assessment tool represent a snapshot of a network's 
security at a particular point in time. Thus, vulnerability assessment tools determine 
where in a network an attack is possible. 
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Vulnerability assessment tools typically use two methodologies, either 
separately or in conjunction, for performing the network examination: (1) an active 
inspection of a network that launches known malicious attacks against the network 
to determine the network's susceptibility to those attacks; and/or (2) a passive 
5 inspection of a network that inspects the network's device and service 
configurations (known as service banners) for particular settings that are known to 
be vulnerable to attacks. 

The active methodology actually reenacts a series of known attacks, 
recording the results of the attacks to discover vulnerabilities in the network. 
10 "Known attacks" are generally the methods and exploit scripts that can be 
commonly referenced on security related Internet locations or sites (e.g., 
www.rootshell.com) and mailing lists (e.g., BUGTRAQ) that are also often referred 
to by hackers (also referred to as crackers) to construct attacks on a network or 
individual machine. Using this active methodology, a vulnerability is discovered 
1 5 when the reenacted attack is able to penetrate the network and, in many instances, 
"crash" or disable the network. Obviously, a severe limitation of this methodology 
is that an undue risk is put on the network being tested. For instance, should a 
vulnerability be detected by the test attack resulting in a network crash, information 
on the network may be lost. 
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The passive methodology does not subject the network to the undue risk of 
the active methodology, but it has other limitations. The passive methodology 
checks packet information, commonly known as "service banners/' that identifies 
network services and devices. The service banner is used to check a database of 
5 known vulnerabilities for that particular service banner. 

A service banner generally contains four fields. For example, consider the 
following sample service banner: 

220-FTP Server (wuftpd 2.4.2) ready. 
In this example, Field 1 is the number 220, and is a reply code indicating the service 
10 is ready for a new user. Field 2, here "FTP Server," identifies the type of service 
being used. Field 3 , here "(wuftpd 2.4.2) " indicates the software and version of the 
service. And Field 4, "ready," is a message indicating that the service is ready for 
user supplied input. 

The service banner is easily obtained from a network by using telnet to 
1 5 access ports on which services processes are resident. The telnet protocol will be 
understood by those in the art, and is described in the RCF-764, "Telnet Protocol 
Specification", J. Postel, June 1, 1980 (available at www.ietf.org/rfc). In this 
methodology, the service banner is then compared against a database of service 
banners that have a list of known vulnerabilities. 
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While the passive methodology may be safer than the active methodology, 
it is not accurate or reliable for many reasons. First, service banners are easily 
configurable and may not accurately name the type of network service enabled on 
a host. Thus, in the service banner example above, the service is defined in fields 

5 2 and 3 of the banner as FTP Server (wuftpd 2.4.2). That service may be 
reconfigured easily by an individual so that the network service is no longer 
accurately described by the service banner. Therefore, any vulnerability detected 
for the inaccurate device or service would be a false detection. In particular, 
hackers will commonly attempt to hide any "back doors" or vulnerabilities found in 

10 a network by editing the service banner information so that another hacker will not 
be able to notice a quick entrance into the network. Some vulnerabilities are 
therefore hidden from this passive methodology. 

Another reason using service banners is unreliable is that service banners do 
not accurately reflect the patch level of the network service and therefore critical 

15 fixes to the network may have been applied that are not reflected in the service 
banner. Patch levels refer to the degree to which the source code of the service or 
program has been modified by functionality or security fixes. A patch is understood 
as a specific alteration in the code of a service or program for the purpose of 
altering some specific aspect of the service or program's functionality or eliminating 

20 a bug or security risk. 
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Still another reason that use of service banners as a means of vulnerability 
detection is undesirable is that it places systems on the network in undue risk. In 
particular, service banners must be openly displayed in order for the presence of 
vulnerabilities in a network to be inferred. As such, the service banners are available 
5 to any remote user, malicious or otherwise. A common method of network 
reconnaissance employed by hackers is to examine the service banners on machines 
across a network in order to identify vulnerable points of attack. 

One alternative to these two methodologies (active and passive) has been 
to use a method of information gathering known as "fingerprinting;' This method 
10 is described in the publication entitled "Remote OS Dectection Via TCP/IP Stack 
Fingerprinting" by Fyodor, dated October 18, 1998. This publication describes a 
"fingerprinting" of the operating system of machines on a network for purposes of 
determining the operating system type. Once an operating system is known, then 
other techniques may be employed to assess a vulnerability (fingerprinting does not 
1 5 itself assess vulnerabilities) . 

Nonetheless, while fingerprinting can identify the operating system in some 
instances, it cannot always do so accurately, and it cannot identify the patch level 
of the operating system. Moreover, while fingerprinting can sometimes identify 
active ports in use by a host, it cannot always do so accurately and it cannot identify 
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the services that are running on those ports. All of these deficiencies limit the 
accurate detection of vulnerabilities. 

A need therefore exists for a method and system of detecting vulnerabilities 
that does not subject the network being analyzed to undue risks (unlike the active 
5 approach), is accurate and reliable (unlike the passive approach), and is able to 
accurately identify more information from the network than only the operating 
system (unlike the Fyodor approach). A further need exists for a method and 
system that not only detects current vulnerabilities of a network, but also infers 
vulnerabilities not yet existing on the network. 

10 

SUMMARY 

A system and method in accordance with the invention reliably and non- 
intrusively identifies various conditions of a network. In particular, an embodiment 
of the invention can identify an operating system, including version and patch level, 

15 and a service, including version and patch level, of a remote host on the network. 
Using this information, an embodiment of the invention can then reliably identify a 
vulnerability condition of the network. In some embodiments, the operating system 
and service information can be used to identify a trojan application, unlicensed 
software use, security policy violations, or even infer vulnerabilities that are yet 

20 unknown. 
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One embodiment of the invention sends several sets of packets to a remote 
host on a network and based on the responses to those packets identifies the 
operating system (including version and patch level) and services (including version 
and patch level) operating on the host. Specifically in one embodiment, three sets 
5 of packets are sent to a host to identify the operating system. The responses to each 
set of packets are reflexively (automatically) produced by the host and do not 
undesirably intrude upon the host in any way. When responses are received they are 
compared to a database of "reflex signatures." The comparison yields some 
information about the operating system. Based on this information, the responses 

10 to the first set of packets are used to tailor the second set of packets. Likewise, the 
responses to the second set of packets are used to tailor the third set of packets. 
The three sets of responsive packets are used to accurately identify the operating 
system, including its version and patch level, of a particular host. 

The operating system information identified is then used to tailor packets to 

15 send to the host to identify the services operating on the remote host. In one 
embodiment and in a similar manner to that done for the operating system, two sets 
of packets are sent to the host to identify the services, including version and patch 
level, operating on the host. 

The information gleaned from identifying the services will allow the 

20 determination of vulnerabilities on the network or other information. 
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In this manner, a network can be examined in a non-intrusive and efficient 
manner to accurately assess network vulnerabilities. 

BRIEF DESCRIPTION OF THE DRAWINGS 
5 The present invention will be described with respect to particular 

embodiments thereof, and reference will be made to the drawings in which: 
FIG. 1 is a block diagram of an IP packet; 

FIG. 2 is a functional block diagram of an embodiment of a system in 
accordance with the present invention; and 
10 FIGs. 3-4 illustrate a flow chart of an embodiment of a method in 

accordance with the present invention. 

DETAILED DESCRIPTION 
A system in accordance with the invention is designed to provide a fast, yet 
15 non-invasive vulnerability testing system that provides high confidence in results. 
Unlike conventional systems, a system in accordance with the invention first 
determines the operating system, including version number, that is running on the 
host under test. To do so, a system in accordance with the invention takes 
advantage of the fact that each host operating system responds to non-traditional 
20 packets differently. Therefore, by sending certain selected packets to a host, the 
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responsive packets returned by the host can be used to identify the operating system 
running. Hence, a process performed in accordance with the invention is sometimes 
referred to herein as "reflex testing." Once the operating system is identified, 
services that are running on a host can be determined and ultimately potential 
vulnerabilities are identified. 

System Overview 

FIG. 2 is a high-level functional block diagram of a system 200 in 
accordance with an embodiment of the present invention that is to perform 
vulnerability testing on network 23 5 . The system 200 generally includes three core 
components including a scanning coordination component 210, a database 
component 215, and a scan analysis component 220. In some embodiments, a 
reporting component 225 is also included for generating various reports. It is noted 
that this system 200 may be distributed geographically or may be part of a system 
at one particular location. Thus, the system 200 may be remote from the network 
235 and the transmissions 230 to and from network 235 may be over a 
telecommunications network, a wireless network, or over a network such as the 
Internet in various embodiments. 

The scanning coordination component 210 initiates the testing (scanning) 
procedure. It instantiates scanning processes 240, each of which is responsible for 
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scanning a host 236 on network 235. Scanning processes 240 are also sometimes 
referred to as scanning engines or scanning daemons. Each scanning process 240 
constructs and sends custom packets to a host on network 235 and receives packets 
back from the hosts. Each scan process 240 is functionally distinct from other scan 

5 processes 240 in that each sends data to a distinct host under test and relays this 
data to the scan analysis component 220 independently of other scan processes. 
Scanning coordination component 210 spawns as many scanning processes 240 as 
required for complete scanning of all hosts on network 235. 

Once data is gathered by a scan process 240 regarding a host on network 

10 235, then the data is sent by the scan process 240 to scan analysis component 220. 
The scan analysis component 220 analyzes data sent from the scan process 240 and 
communicates with the scan coordination component 210 based on the results of 
that analysis. 

In one embodiment, when scan analysis component 220 receives a data 
15 packet for a particular host, scan analysis component compares the received data 
to data stored in database component 215, which stores information regarding 
known operating systems, services, and vulnerabilities. The scan analysis 
component 220 in some embodiments also performs various analyses on incoming 
data for the purpose of drawing inferences about the presence of other 
20 vulnerabilities on the network 23 5 . 
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Scan analysis component 220 then communicates the relevant information 
to scan coordination component 21 0, which also accesses database component 215 
to initiate a next appropriate scan process 240 for further testing. The scan analysis 
component 220 also relays relevant information to other peripheral components of 
5 system 200, such as reporting component 225, for performance of audits, etc. 

As will be understood by those of skill in the art, while all or part of a 
system 200 can be implemented in hardware, an embodiment of a system 200 in 
accordance with the invention and as described herein is a set of object-oriented 
components that dynamically interact to perform the steps for vulnerability 

10 detection, vulnerability analysis, and reporting functions as described. Thus, as 
object-oriented components, the system 200 is a software- or firmware-based 
system that includes processor readable code that is practically implemented in a 
computer system, such as a desktop-computer-type system (e.g., a PC), the system 
described in Provisional Application Serial No. 60/150,905 with respect to Fig. 7 

15 and incorporated by reference herein, or virtually any other type of computing 
system that includes the ability to read and execute the software code, usually 
including a processor and memory. 

20 
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Methodology 

FIGs. 3-4 illustrate a generalized flow chart of an embodiment of a method 
in accordance with the present invention. FIGs. 3-4 illustrates the steps of first 
determining a plurality of network conditions, including identifying an operating 
5 system condition and service condition, and then using those conditions to identify 
vulnerabilities. 

Step 10 first identifies an operating system condition of the host, and in 
some embodiments includes identifying an operating system type, version, and patch 
level. Step 310 is divided into three phases, P1-P3. PI 312 first begins to 

10 determine an operating system of a host on network 235 (FIG. 2). P2 3 14 further 
determines the operating system for the host. P3 3 16 finalizes the determination of 
the operating system. P2 uses information determined from PI, and, likewise, P3 
uses information determined from P2. As such, phases 312, 314, and 316 are 
dependent on each other for determining the conditions of the remote host on 

1 5 network 23 5 . As should be understood, packets sent in each phase are generated 
by one or more scanning processes 240. 

The following description discusses the types of packets sent and received 
in accordance with an embodiment of the invention. A person of ordinary skill in 
the art will generally be familiar TCP/IP packet formation and structure and will 

20 generally be familiar with the teaching of W. Richard Stevens, "TCP/IP Illustrated/' 
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Vols. 1-4 (Addison-Wesley 1994); Douglas E. Corner, "Internetworking with 
TCP/IP," Vols. 1-3 (4 th Ed., Prentice Hall, 1995, 2000); or other similar reference. 

A network under test will be defined by a range of addresses. In PI 312, 
a scanning process 240 first transmits a first set of test packets all of the addresses 
5 in the range for the network 235, where the packets are addressed in accordance 
with CIDR (Classless InterDomain Routing), described in detail in RFC-1519. 
Hosts at active addresses will respond to at least one of the packets sent (described 
in more detail below). As a result of PI, hosts on the network are identified and, 
based on the information sent in responsive packets, the system can start to identify 
1 0 the operating systems of each host. 

In one embodiment, there are four types of test packets S 1 -S 4 that are sent 
in sequence from a scan process during this phase PI to each network address: 

S 2 : a SYN packet with false flag in the TCP option header. 

S 2 : a Fragmented UDP packet with malformed header (any header 
15 inconsistency is sufficient), where the packet is 8K in size. 

S 3 : a FIN Packet of a selected variable size or a FIN packet without the 
ACK or SYN flag properly set. 

20 S 4 : a generic, well-formed ICMP ECHO request packet. 

It is to be understood that although the above-listed types of test packets are used 

in one embodiment, other types of test packets may be used in other embodiments 

of the invention yet fall within the scope of the present invention. Further although 
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four test packets (S x ... S 4 ) are illustrated, it is to be understood that in other 

embodiments more or fewer test packets could be sent. 

The test packets (S t ... S 4 ) sent to each host initiate a "reflex test". That is, 

the set of packets is sent to encourage an automatic response or "reflex" from a 

host. Listed below is a set of reflex packets R X ...R 4 that, based on the inventors 5 

experience, are typically returned in response to the test packets S L . . . S 4 . As should 

be understood, each packet in the set of packets generally elicits a corresponding 

automatic response from the host, i.e., reflex packet R t is sent in response to test 

packet S l3 R 2 to S 2 , etc. 

R x : The host usually returns a packet with the S YN and ACK flags set, 
an 8 Byte header, and no data. The correct behavior based on 
RFC-793 is not to respond to this packet, however, a large number 
of systems do not follow the RFC in this regard. 

R 2 : The host usually returns a reassembled packet with the ACK bit set 
and a value in the fragment offset field. 

R 3 : The returned packet varies, depending upon the implementation of 
the TCP stack. Based on RFC 793 (which can be found at 
wwwietf org/rfc), the expected response from the remote system is 
not to respond, but some systems return a packet with the RST 
(Reset) bit set. 

R 4 : The host usually returns a packet with a variable length ICMP 
header and a packet with the ECHO REPLY option set. 

Each operating system responds to the test packets differently. In some 

cases, packets distinct from those described above are returned and in some cases 

no packet is returned in response to a particular test packet. Further, the order in 



Attorney Docket No. :HVWD1001US0MEM/SBS 
sbs/hvwd/1 00 1/100 lusO.OO 1 



- 18- 



which packets are returned will frequently vary. In all cases, the response packet 
(or lack thereof) contains information which is useful to begin to identify the 
operating system on a particular host. For instance, a host running Solaris will 
respond differently to some packets than a host running Windows. Therefore, 
5 based on a host's response to the set of test packets (S x ... S 4 ), this returned set of 
reflex packets is generally sufficient to initially infer operating system conditions of 
the host by comparing the responses (by scan analysis component 220) to a 
preexisting database 215 of possible responses or "reflex signatures." 

Based on information communicated from scan analysis component 220 to 
10 scan coordination component 210 regarding the operating system of the host, 
phase 2, P2 314, further determines the operating system conditions of the host 
using the first set of reflex packets from P 1 . More specifically, the information 
received in the responsive packets from PI is used to refine the contents of test 
packets sent in P2. 

15 As with PI, when compared by scan analysis component 220 to a 

preexisting database 215 of "reflex signatures," the responses to the test packets 
S 5 ...S g provide data that makes it possible to further identify additional operating 
system conditions of the remote host. The second set of test packets S 5 ...S 8 
involves sending packets directly to the remote host, and includes: 
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S 5 : a generic well-formed TCP Header set to 1024 bytes in size. 
S 6 : a packet requesting an ICMP Timestamp. 

S 7 : a packet with min/max segment size set to a selected variable value. 
S 8 : a UDP packet with the fragment bit set. 
5 The second set of reflex packets from the host usually includes (based on the 

inventors' experience): 

R^: a TCP initial window set to a non-zero value. 
R^: an ICMP timestamp reply. 

R 7 : a packet with a segment size that varies depending on S 7 . 
10 R 8 : a UDP packet or a packet with the SYN and ACK flags set. 

Phase 3, P3 3 16, further determines the operating system conditions for the 
host. Again, based on information communicated from scan analysis component 
220 to scan coordination component 210 regarding information received in P2, 
packet contents inP3 are refined. P3 transmits a third set of test packets S 9 ...S 14 
15 to the host as follows: 

S 9 : a TCP packet with the header and options set incorrectly. 

S 10 : a well-formed ICMP packet. 

S u : a fragmented TCP or UDP packet. 

S 12 : a packet with an empty TCP window or a window set to zero. 
20 S 13 : a generic TCP packet with 8K of random data. 
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S 14 : a SYN packet with ACK and RST flags set. 

The third set of reflex data packets R^.R^ from the host usually includes 

(based on the inventors' experience): 

R^ a packet with a 0 sized header or no response. 

5 R 10 : a packet that will vary depending upon the service and the host's 

implementation of the TCP/IP stack. 

R n : a packet containing packet sequence information. 

R 12 : a TCP packet having a header with offset information. 

R 13 : a packet with the ACK flag set and the segment size bit set. 

10 R 14 : a packet with the ACK or RST bits set 

By comparing the returned data in reflex packets R^.R^ (as well as 

R^.-Rg) to a database 215 containing "reflex signatures", not only can the operating 

system type be identified (e.g., Solaris or Windows) but the version and patch level 

can be reliably identified as well. 

15 For instance, each operating system version and patch level will result in 

differing responses to the test packets in P1-P3. A host running Solaris 2.5 will 

respond differently than one running Solaris 2.6 will respond differently from one 

running Windows 98. Using a three phase sequence of packets, enough information 

can be efficiently gathered to reliably identify operating system conditions, including 

20 type, version, and patch level. 
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After the operating system conditions are identified in step 310, the service 
conditions for a host are next identified in step 320. First the open ports on the 
remote host are determined and then the processes listening on those ports are 
determined. A comprehensive list of sample ports available to be tested includes, 
5 but is not limited to: 

3com-tsmux; 3ds-lm; 31-11; 3m-image-lm; 914c-g; 9pfs; 

BackOrifice; BackOrifice2k; InCommand Trojan; NetBus-12345; 

NetBus-12346; Object Server; Remote File Sharing; 

Stacheldraht Master; Trinoo Control; Trinoo Registration; Trinoo 
10 Slave; XI 1; aal-lm; abbaccuray; about; acas; accelx; 

accessbuilder; aci; acmaintdbd; acmaint_transd; acmsoda; acp; 

acr-nema; adapt- sna; aed-512; af; afpovertcp; afs; afs3-bos; 

afs3 -callback; afs3 -errors; afs3 -fileserver; afs3 -kaserver; 

afs3-prserver; afs3-rmtsys; afs3 -update; afs3-vlserver; 
15 afs3-volser; airs; alpes; alta-ana-lm; amanda; amandaidx; 

amidxtape; ampr-info; ampr-inter; anet; ansanotify; ansatrader; 

ansoft-lm- 1 ; ansoft-lm-2; anynetgateway; aol; aol- 1 ; aol-2; 

aol-3; apertus-ldp; apple-licman; appleqtc; appleqtcsrvr; applix; 

apri-lm; arcisdms; ariell; ariel2; ariel3; arns; as-servermap; asa; 
20 asa-appl-proto; asip-webadmin; aspeclmd; aspentec-lm; at-3; 

at-5; at-7; at-8; at-echo; at-nbp; at-rtmp; at-zis; atex elmd; 

atls; atm-zip-office; ats; audio-activmail; audionews; audit; 

auditd; aurora-cmgr; aurp; auth; autodesk-lm; avian; axon-lm; 

banyan-rpc; banyan-vip; bbn-mmc; bbn-mmx; bdp; bftp; bgmp; 
25 bgp; bgpd; bgs-nsi; bh611; bhevent; bhfhs; bhmds; biff; 

biimenu; bind; bl-idm; blackboard; blackjack; blueberry-lm; 

bmap; bnet; bootclient; bootpc; bootps; bootserver; btx; 

busboy; bwnfs; bytex; cab-protocol; cableport-ax; cacp; cadis- 1; 

cadis-2; cadkey-licman; cadkey-tablet; cadlock-1000; 
30 cadlock-770; cadsi-lm; cal; callbook; canna; ccmail; cdc; 

cdfiinc; cfdptkt; cfengine; cfingerd; cfs; chargen; 

checkpoint-fwz; checksum; chromagrafx; chshell; cichild-lm; 

cichlid; cisco-fha; cisco-sys; cisco-tna; citadel; cl-1; clearcase; 

cloanto-net-1; clvm-cfg; cmip-man; coauthor; codaauth2; 
35 codasrv; codasrv-se; commerce; commplex-link; commplex-main; 
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compressnet-2; compressnet-3; comscm; con; concert; conf; 

conference; confluent; connlcli; contentserver; courier; covia; 

creativepartnr; creativeserver; cronus; crs; csdm-1468; 

csdm-1472; csdmbase-1467; csdmbase-1471; csi-sgwp; csnet-ns; 
5 ctf; cucme-1; cucme-2; cucme-3; cucme-4; cuillamartin; custix; 

cvc; cvcjiostd; cvspserver; cybercash; cycleserv; cycleserv2; 

cypress; cypress-stat; dantz; dasp; datasurfsrv; datasurfsrvsec; 

datex-asn; dayna; daytime; dbase; dbbrowse; dberegister; 

dbreporter; dbsa-lm; dbstar; dc; dca; dcp; dcs; ddm-dfim; 
10 ddm-rdb; ddm-ssl; dec-notes; decap; decauth; decbsrv; 

decladebug; dectalk; decvms-sysmgt; deos; deslogin-2005; 

deslogin-3005; deslogind; device; device2; deviceshare; 

dhcpv6-client; dhcpv6-server; diagmond; digital-vrc; direct; dis; 

discard; distrib-netassholes; dixie; dlip; dls-197; dls-2047; 
15 dls-mon; dls-monitor; dlsrpn; dlswpn; dmdocbroker; 

dn6-nlm-aud; dn6-smm-red; dna-cml; dnsix; docstor; domain; 

doom; down; dpsi; dsETOS; dsf; dsfgw; dsp; dsp3270; 

dtag-ste-sb; dtk; dtspc; dvl-activemail; dvs; dwf; echo; 

echo-udp; editbench; efs; eicon-server; eicon-slp; eicon-x25; 
20 eklogin; ekshell-2106; ekshell-545; elan; elcsd; ellpack; 

embl-ndt; emce; emfis-cntl; emfis-data; entomb; entrustmanager; 

entrusttime; equationbuilder; erpc; esl-lm; esro-gen; essbase; 

eudora-set; evb-elm; exchange; exec; eyelink; fatserv; fax; 

fc-cli; fc-ser; fcp; fhc; fics; finger; flexlm; fln-spx; fodms: 
25 font-service; ftp; ftp-agent; ftp-data; ftsrv; fujitsu-dev: 

fujitsu-dtc; fujitsu-dtcns; funkproxy; gacp; gandalf-lm; garcon; 

gdomap; gdp-port; genie; genie-lm; genrad-mux; ginad; globe: 

glogger; go-login; goldleaf-licman; gopher; gppitnp; graphics: 

gridgen-elmd; gss-http; gss-xlicen; gtegsc-lm; gv-us; gwha: 
30 hacl-cfg; hacl-gs; hacl-hb; hacl-local; hacl-probe; hacl-test: 

hassle; hdap; hecmtl-db; hems; here-lm; hermes; hiq; hostname; 

hosts2-ns; hp-3000-telnet; hp-alarm-mgr-3 83 ; hp-alarm-mgr-783: 

hp-collector-3 8 1 ; hp-collector-78 1 ; hp-managed-node-3 82; 

hp-managed-node-782; http; http-alt; http-mgmt; http-proxy; 
35 http-rpc-epmap; https; hybrid; hybrid-pop; hylafax; hyper-g: 

iadl; iad2; iad3; iafdbase; iafserver; iasd; ibm-app; ibm-cics: 

ibm-db2; ibm-mqseries; ibm-pps; ibm-res; ibm_wrless_lan; ica; 

icad-el; icb; iclpv-dm; iclpv-nlc; iclpv-nls; iclpv-pm; iclpv-sas: 

iclpv-sc; iclpv-wsm; idfp; ies-lm; ifor-protocol; igi-lm; iiop; iis4: 
40 imap2; imap3; imap4-ssl; imsldoc; imsp; imtc-mcs; infoman: 
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informatik-lm; infoseek; ingres-net; ingreslock; innosys; 
innosys-acl; insitu-conf; instlbootc; instl boots; intecourier; 
integra-sme; intellistor-lm; interbase; interhdl_elmd; intrinsa; 
intuitive-edge; invokator; ipcd; ipcserver; ipdd; ipx; ire; 
irc-6667; irc-6668; irc-serv-529; irc-serv-6666; is99c; is99s; 
isakmp; isi-gl; isis; isis-bcast; iso-ill; iso-ip; iso-tpO; iso-tsap; 
iso-tsap-c2; isode-dua; issd; ivs-video; ivsd; jetdirect; kauth; 
kerberos; kerberos-adm; kerberos-sec; kerberosmaster; 
keyserver; kip; kis; klogin; knet-cmp; kpasswd; kpasswd5; 
kpop; krb524; krb_prop; krbupdate; kryptolan; kshell; kx; 
la-maint; lam; lansource; laplink; ldap; legent-1; legent-2; 
liberty-lm; licensedaemon; link; linuxconf; linx; listen-2766; 
ljk-login; loadsrv; loc-srv; localinfosrvr; lockd; locus-con; 
locus-map; login; lonewolf-lm; lotusnote; lupa; macon-udp; 
magenta-logic; mailbox; mailbox-lm; mailq; maitrd; man; 
mapper-mapethd; mapper-nodemgr; mapper-ws_ethd; marcam-lm; 
matip-type-a; matip-type-b; mciautoreg; mcidas; mdbsdaemon; 
meta-corp; metagram; meter; mfcobol; mftp; micom-pfs; 
micromuse-lm; microsoft-ds; mimer; miroconnect; mit-dov; 
mit-ml-dev-83; mit-ml-dev-85; miteksys-lm; mloadd; mm-admin; 

mmcc; mobileip-agent; mobilip-mn; molly; mondex; monitor; 

montage-lm; mortgageware; mount; mpm; mpm-flags; mpm-snd; 

mpp; mptn; ms-rome; ms-shuttle; ms-sna-base; ms-sna-server; 

ms-sql-m; ms-sql-s; msg; msg-auth; msg-icp; msljmd; msp; 

msql-1112; msql-4333; msrdp; multiplex; mumps; mvx-lm; 

mylex-mapd; mysql; nameserver; namp; ncd-conf; ncd-conf-tcp; 

ncd-diag; ncd-diag-tcp; ncd-pref; ncd-pref-tcp; need; ncld; ncp; 

ncube-lm; ndm-requester; ndm-server; ndsauth; nerv; 

nest-protocol; netbios-dgm; netbios-ns; netbios-ssn; netcheque; 

netcp-395; netcp-740; netgw; netlabs-lm; netmap lm; netnews; 

netrcs; netrjs-1; netrjs-2; netrjs-3; netrjs-4; netsc-dev; 

netsc-prod; netstat; netview-aix-1; netview-aix-10; 

netview-aix- 1 1 ; netview-aix- 12; netview-aix-2; netview-aix-3 ; 

netview-aix-4; netview-aix- 5; netview-aix-6; netview-aix-7; 

netview-aix-8; netview-aix-9; netviewdml; netviewdm2; 

netviewdm3; netwall; netware-csp; netware-ip; new-rwho; 

newacct; news- 144; news-2009; nextstep; nfa; nfs; 

nfsd-keepalive; nfsd-status; ni-ftp; ni-mail; nicname; nim; 

nimreg; nip; nkd; nlogin; nms; nms_topo_serv; nmsp; nnsp; 

nntp; notify; novastorbakcup; novell-lu6.2; npmp-gui; 
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npmp-local; npmp-trap; npp; nqs; nrcabq-lm; ns; nsiiops; 

nss-routing; nsw-fe; ntalk; nterm; ntp; nucleus; nuts_bootp; 

nuts_dem; objcall; objective-dbc; objectmanager; oc-lm; 

ocbinder; oceansoft-lm; ock; ocsamu; ocscmu; ocserver; 
5 odmr; ohimsrv; omserv; onmux; opalis-rdv; opalis-robot; 

opc-job-start; opc-job-track; openmath; openport; 

openvms-sysipc; ora-lm; oracle; orasrv; os-licman; ospfd; 

osu-nms; p3pw; pacerforum; padl2sim; passgo; password-chg; 

pawserv; pciarray; pcmail-srv; pcnfs; pdap; pdap-np; pegboard; 
10 pehelp; peport; perf-port; personal-link; ph; philips-vc; phone; 

phonebook; photuris; pim-rp-disc; pip; pipe server; pipes; pirp; 

pop-2; pop-3; postgres; pov-ray; powerburst; ppp; pptp; 

print-srv; printer; priv-dial; priv-file; priv-mail; priv-print; 

priv-rje; priv-term; priv-term-1; prm-nm; prm-nm-np; prm-sm; 
15 prm-sm-np; profile; prosharel; proshare2; proshareaudio; 

prosharedata; prosharenotify; prosharerequest; prosharevideo; 

prospero; proxima-lm; prsvp; ptcnameservice; puparp; pwdgen; 

qbikgdp; qft; qmqp; qotd; qrh; quotad; radacct-1646; 

radacct-1813; radius- 1645; radius- 18 12; raid-ac; raid-am-2007; 
20 raid-am-2013; raid-cc-2006; raid-cc-2011; raid-cd; raid-cs; 

raid-sf; rap-256; rap-38; rap-listen; rap-service; rcmd; rep; rds; 

rds2; re-mail-ck; relief; rellpack; remote-kis; remotefs; rexec; 

rfa; rfe; rfx-lm; rgtp; ricardo-lm; rightbrain; rimsl; ripd; ripng; 

ripngd; ris; ris-cm; rje ; rkinit; rlogin; rip; rmonitor; 
25 rmonitor_secure; rmt; rna-lm; robcad-lm; route; rpasswd; 

rpc2portmap; rplay; rrh; rsh-spx; rsvd; rsvp_tunnel; rtelnet; rtip; 

rtsclient; rtsp; rtsserv; rwhois; rwrite; rxe; s-net; sae-urn; saft; 

sas-1; sas-2; sas-3; sbook; sec-security; sco-websrvrmg3 ; 

scohelp; scoi2odialog; scoremgr; scrabble; screencast; sex-proxy; 
30 sd; sdadmind; sdfiinc; sdlog; sdnskmp; sdreport; sdsc-lm; 

sdserv; sdxauthd; search; secureidprop; securid; semantix; send; 

servexec; servserv; set; sfs-config; sfs-smp-net; sftp; sgcp; 

sgi-dgl; sgmp; sgmp-traps; shadowserver; shell; shiva confsrvr; 

shivadiscovery; shivahose; shivasound; shois; shrinkwrap; siam; 
35 sift-uft; silverplatter; simap; simba-cs; sj3; skkserv; skronk; 

smakynet; smartsdp; smip-agent; smpte; smsd; smsp; smtp; 

smtps; smux; snagas; snare; snews; snmp; snmp-tcp-port; 

snmptrap; snpp; sntp-heartbeat; socks; softcm; softpc; sonar: 

sophia-lm; spc; spsc; sql*net; sql-net; sqlserv; sqlsrv; 
40 squid-http; squid-ipc; sre; srmp; srssend; ss7ns; ssh; statscil-lm: 
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statsci2-lm; statsrv; stel; stmf; stone-design- 1; streettalk; 

stun-pl; stun-p2; stun-p3; stun-port; stx; su-mit-tg; submission; 

submit; submitserver; subntbcstjftp; sunrpc; supdup; supfiledbg; 

supfilesrv; support; sur-meas; svrloc; swift-rvf; symplex; 
5 synoptics-trap; synotics-broker; synotics-relay; sysiog; systat; 

tabula; tacacs; tacacs-ds; tacnews; taligent-lm; talk; tarn; 

tcp-id-port; tcpmux; tcpnethaspsrv; teedtap; telefinder; 

telelpathattack; telelpathstart; telesis-licman; telnet; tempo; 

tenebris_nts; terminaldb-2008; terminaldb-2018; tftp; ticf-1; 
10 ticf-2; timbuktu; timbuktu-srvl; timbuktu-srv2; timbuktu-srv3 ; 

timbuktu-srv4; time; timed; timeflies; tlisrv; tn-tl-fdl; tn-tl-w2; 

tnETOS; tns-cml; tpdu; tpip; tr-rsrb-pl; tr-rsrb-p2; tr-rsrb-p3; 

tr-rsrb-port; track; trofF; tserver; ttyinfo; uaac; uaiact; uarps; 

udt_os; ufsd; uis; ulistserv; ulp; ulpnet; umeter; unicall; 
15 unidata-ldm; unify; unitary; ups; ups-onlinet; urm; us-gv; utcd; 

utime; utmpcd; utmpsd; uucp; uucp-path; uucp-rlogin; 

valisys-lm; vat; vat-control; vemmi; venus; venus-se; vettcp; 

via-ftp; vid; video-activmail; videotex; virtual-places; 

vistium-share; vlsi-lm; vmnet; vmodem; vmpwscs; vnas; vpac; 
20 vpad; vpvc; vpvd; vsinet; vslmp; watcom-sql; watershed-lm; 

webster-2627; webster-765; who; whoami; whosockami-2009; 

whosockami-2019; wincim; wins; wizard; wnn6; wnn6_Cn; 

wnn6_DS; wnn6_Kr; wnn6_Tw; work-sol; world-lm; wpages; 

wpgs; www-dev; x25-svc-port; xaudio; xdmcp; xdsxdm; xfer; 
25 xinuexpansionl; xinuexpansion2; xinuexpansion3; xinuexpansion4; 

xinupageserver; xlog; xnmp; xns-auth; xns-ch; xns-courier; 

xns-mail; xns-time; xribs; xtreelic; xvttp; xyplex-mux; yak-chat; 

z39.50; zannet; zebra; zebrasrv; zephyr-clt; zephyr-hm; zion-lm; 

zserv; (1100 rows). 

30 

A series 322 of FIN, SYN, or generic TCP packets (that are RFC 
compliant) are sent to potential ports for the host. It should be noted that because 
the operating system is known, a set of potential ports is also known. In other 
words, not all operating systems will use the same open ports or services, and the 
35 information obtained in step 3 10 is used to select the packets (and content of those 
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packets) to be sent. The responses to the set of test packets in phase P4 322 
identifies open ports and some initial characteristics of services on those ports. This 
identification is a result of comparing information in the responses to that stored on 
database 215. The RFCs are very specific about how a service should respond to 
5 a given input and, therefore, the reflex response methodology can be used to 
accurately determine the specific service on a given port. It should be noted that 
there are thousands of RFCs that specify how remote host applications and services 
interact with TCP/IP networks and that each RFC speaks to the specific conditions 
that should be tested on a remote network. 
10 For example, sending an "SYST" command to a port that is suspected of 

running FTP (c.f. RFC 959 "File Transfer Protocol") will respond with the type of 
operating system on the server, with the first word of the reply being the system 
name. 

Example: 

1 5 220 foo.com FTP Server 

SYST 

215 UNIX Type: L8 

Finally, in phase 5, P5 324, an additional set of packets is sent based on the 
20 results of P4. The additional set of at least one packet can be used to further 
determine service conditions. Ultimately, not only is the operating system type, 
version, and patch level identified for a host, but also each host service is identified 
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with a version and patch level. When the service conditions are analyzed step 330, 
by comparison to database 215 or otherwise, vulnerabilities of the host (and, thus, 
the network) can be identified in a reliable and non-intrusive manner. 

The following examples are responses from a telnet service (c.f RFC 200, 
5 595, 596, 306, 288, and 2828) on a Solaris 2.6 system with a packet reply that 
occurs prior to the telnet connection being properly established by the remote host: 

Example 1 

192.168.0.100 -> 192.168.1.100:22577 TCP TTL:244TOS:0x0ID:30216 DF 
*****PA* Seq: 0xD6A4A4C4 Ack: 0xA3112DF9 Win: 0x2328 
1 0 TCP Options => NOP NOP TS: 128361854 19495 

FF FD 18 FF FD IF FF FD 23 FF FD 27 FF FD 24 #..*..$ 

Example 2 

192.168.0.100 -> 192.168.1.100:25960 TCP TTL : 244 TOS: 0x0 ID: 17070 DF 
15 *****pa* Seq: 0xD758B651 Ack: 0xA3C305F2 Win: 0x2328 

TCP Options => NOP NOP TS: 128370508 19668 

FF FE 24 FF FA 18 01 FF F0 FF FA 23 01 FF F0 FF ..$ #.... 

FA27 01FFF0 



20 These examples illustrate that two different versions of telnet will generate 

unique responses. From the first example, the service can be identified. From the 
second example, the service, version, and patch level can be identified. An 
additional packet (or set of packets) may be desirable to send to the port in the first 
example to further identify the version and patch level for the services. 

25 Although the above-described embodiment of the invention is described with 

five sequences of test packets being sent to identify the type, version, and patch 
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level of both the operating system and services operating on the remote host, other 
embodiments use more or fewer sequences to identify similar information. 

The advantages of the methodology of the present invention are numerous. 
A method in accordance with the present invention provides vulnerability 
5 assessment that is clearly defined, fast, accurate, reliable, and non-intrusive to 
remote systems. A method in accordance with the present invention is difficult to 
detect by and does not appear as a standard intrusion to the network analyzed. 

Moreover, a method in accordance with an embodiment of the invention is 
able to add new vulnerabilities and may also locate vulnerabilities not yet found. 
10 Such new vulnerabilities can be inferred from information stored in database 215 
when analyzing new reflex signatures. 

In addition to identifying vulnerabilities of a network, an embodiment of the 
invention could be adapted to determining if there were unauthorized applications 
on the system or software license violations. Further, another embodiment of the 
15 invention could be adapted to identifying "trojan" (malicious) applications on the 
host. 

Good security practices and policies are well-defined in the Site Security 
Handbook, RFC-2196. An embodiment of the invention can identify violations of 
these, or other, practices and policies. 
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As should be understood, the present invention may be embodied in a 
storage medium (media) having instructions stored thereon which can be used to 
program a computer. The storage medium can include, but is not limited to, any 
type of disk including floppy disks, optical disks, DVD, CD ROMs, magnetic 
5 optical disks, RAMs, EPROM, EEPROM, magnetic or optical cards, or any type 
of media suitable for storing electronic instructions. 

Stored on any one of the computer readable medium (media), the present 
invention includes software for controlling both the hardware of the general 
purpose/specialized computer or microprocessor, and for enabling the computer or 

10 microprocessor to interact with a human user or other mechanism utilizing the 
results of the present invention. Such software may include, but is not limited to, 
device drivers, operating systems and user applications. Ultimately, such computer 
readable media further includes software for performing the methods of an 
embodiment of the present invention as described above. 

15 In another embodiment, a method of the present invention may be 

performed over a network. That is, the method of the present invention stored as 
processor readable code, in one embodiment, may be transferred in an electronic 
signal over a network (e.g., the Internet, a frame relay network, an ATM network, 
or a local area network). 
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It should be understood that the particular embodiments described above are 
only illustrative of the principles of the present invention, and various modifications 
could be made by those skilled in the art without departing from the scope and spirit 
of the invention. Thus, the scope of the present invention is limited only by the 
claims that follow. 
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CLAIMS 

What is claimed is: 

5 1 . A method of examining a network, including: 

identifying an operating system of a remote host, including a version and 
a patch level of the operating system; 

identifying a service of the remote host, including a version and a patch 
level of the service; and 
10 identifying a vulnerability of the network based on information obtained 

from the steps of identifying an operating system and identifying a service. 

2. The method of claim 1, wherein: 

the step of identifying an operating system includes sending a first set of 
1 5 packets to the remote host and receiving a second set of packets from the remote 

host in response to said first set of packets; 

the step of identifying a service includes sending a third set of packets to 
the remote host and receiving a fourth set of packets from the remote host in 
response to said third set of packets, wherein information contained in said third 
20 set of packets is based on information received in said second set of packets; 
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the step of identifying a vulnerability includes comparing information 
contained in the second set of packets and the fourth set of packets to preexisting 
information in a database. 

5 3 . The method of claim 1 , wherein the step of identifying an operating system 

includes sending three sets of packets to the remote host and receiving three 
respective sets of responsive packets from the remote host. 

4. A method of examining a network, including: 
1 0 nonintrusively and reliably identifying an operating system of a remote host 

including identifying a version of the operating system; 

nonintrusively and reliably identifying a service of the remote host 
including identifying a version of the service. 

15 5. The method of claim 4 ? further including: 

identifying a vulnerability of the network. 

6. The method of claim 4, further including: 
identifying a trojan application on the host. 

20 
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7. The method of claim 4, further including: 
identifying unauthorized software use on the host. 

8. The method of claim 4 ? further including: 
identifying security policy violations on the network. 

9. The method of claim 4, wherein: 

the step of identifying an operating system further includes identifying a 
patch level of the operating system; 

the step of identifying a service further includes identifying a patch level 
of the service. 

10. The method of claim 4, wherein the steps of identifying an operating 
system and identifying a service each includes: 

sending a selected packet to the remote host; 

receiving from the remote host a reflexive responsive packet. 
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11. The method of claim 4, wherein the steps of identifying an operating 
system and identifying a service each includes: 

sending a plurality of selected packets to the remote host; 

receiving from the remote host a plurality of reflexive responsive packets. 

12. The method of claim 4, wherein: 

the step of identifying an operating system includes sending a first set of 
packets to the remote host and receiving a second set of packets from the remote 
host in response to said first set of packets; 

the step of identifying a service includes sending a third set of packets to 
the remote host and receiving a fourth set of packets from the remote host in 
response to said third set of packets. 

13 . A method of examining a network, including: 

identifying an operating system of a remote host including identifying a 
version of the operating system; 

identifying a service of the remote host including identifying a version of 
the service; and 

identifying a vulnerability of the network. 
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14. The method of claim 13, wherein: 

the step of identifying a vulnerability includes using information obtained 
from the steps of identifying an operating system and identifying a service to 
identify the vulnerability. 

15. The method of claim 13, wherein: 

the step of identifying an operating system further includes identifying a 
patch level of the operating system; 

the step of identifying a service includes identifying a patch level of the 

service. 

16. The method of claim 13, wherein the steps of identifying an operating 
system, identifying a service, and identifying a vulnerability each includes: 

sending a selected packet to the remote host; 

receiving from the remote host a reflexive responsive packet. 

17. The method of claim 13, wherein: 

the step of identifying an operating system includes sending a first set of 
packets to the remote host and receiving a second set of packets from the remote 
host in response to said first set of packets; 
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the step of identifying a service includes sending a third set of packets to 
the remote host and receiving a fourth set of packets from the remote host in 
response to said third set of packets; 

the step of identifying a vulnerability includes comparing information 
5 contained in the second set of packets and the fourth set of packets to information 

in a database. 



18. The method of claim 17, wherein: 

information contained in said third set of packets is based on information 
10 received in said second set of packets; 

information contained in said fifth set of packets is based on information 
received in said fourth set of packets. 



19. A method of examining a network; including: 
15 sending a set of selected packets to a host on the network; 

receiving from the remote host a set of reflexive responsive packets; 

identifying conditions of the remote host by using information received in 
the reflexive responsive packets, wherein the conditions include an operating 
system of the host, and a service of the host. 

20 
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20. The method of claim 19, wherein the conditions further include a 
vulnerability of the host. 

21. The method of claim 19, wherein the conditions further include the 
5 presence of unauthorized software. 

22. The method of claim 19, wherein the conditions include the presence of a 
trojan application. 

10 23 . The method of claim 19, wherein: 

identifying an operating system includes identifying a version; 
identifying a service includes identifying a version. 

The method of claim 19, wherein: 

identifying an operating system includes identifying a version and a patch 
identifying a service includes identifying a version and a patch level. 

20 



15 



24. 



level; 
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25. The method of claim 19, wherein 

the step of sending a set of selected packets to a host on the network 
includes sending a plurality of sets of packets to the host; 

the step of receiving from the remote host a set of reflexive responsive 
5 packets includes receiving a like plurality of sets of reflexive responsive packets. 

26. A method of detecting a vulnerability of a network, comprising: 
sending a first set of selected packets to a host on the network; 
receiving a second set of packets from the remote host in response to the 

1 0 first set of packets; 

sending a third set of selected packets to a host on the network, wherein 
information contained in the third set of packets is based on information contained 
in the second set of packets; 

receiving a fourth set of packets from the remote host in response to the 
15 third set of packets; 

sending a fifth set of selected packets to a host on the network, wherein 
information contained in the fifth set of packets is based on information contained 
in the fourth set of packets; 

receiving a sixth set of packets from the remote host in response to the 
20 fifth set of packets; 
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based on information contained in the second, fourth, and sixth set of 
packets, identifying an operating system of a host on the network, including a 
version and a patch level. 

5 27. The method of claim 26, further including: 

sending a seventh set of selected packets to a host on the network; 

receiving an eighth set of packets from the remote host in response to the 
seventh set of packets; 

sending a ninth set of selected packets to a host on the network; 
10 receiving a tenth set of packets from the remote host in response to the 

ninth set of packets; 

based on information contained in the eight and tenth sets of packets, 
identifying a service of a host on the network, including a version and a patch 
level. 

15 

28. The method of claim 27, further including: 

based on information contained in at least the tenth sequence, identifying 
a vulnerability. 

20 
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29. The method of claim 26, wherein; 
the first set of packets includes: 

a SYN Packet with false flag in the TCP option header; 

a Fragmented UDP packet with malformed header (any header 
inconsistency is sufficient), where the packet is 8K in size; 

a FIN Packets of a selected variable size or a FIN packet without 
the ACK or SYN flag properly set; 

a generic, well-formed ICMP ECHO request packet; 
the third set of packets includes: 

a generic well-formed TCP Header set to 1024 bytes in size; 

a Packet requesting an ICMP Timestamp; 

a Packet with min/max segment size set to a selected variable 

value; 

a UDP packet with the fragment bit set; 
the fifth set of packets includes: 

a TCP Packet with the header and options set incorrectly; 

a well-formed ICMP Packet; 

a Fragmented TCP or UDP packet; 

a packet with an empty TCP window or a window set to zero; 
a generic TCP Packet with 8K of random data; 
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a SYN Packet with ACK and RST flags set. 

30. A method of examining a network, comprising: 
sending a plurality of packets to a network; 

receiving a responsive plurality of packets from the network; 
comparing information in the responsive packets to information stored in 
a database; 

based on the comparison, identifying a plurality of network conditions, 
including a vulnerability of the network. 

31. A method of examining a network, comprising: 
sending packets to a network; 

receiving responsive packets from the network; 

comparing information in the responsive packets to information stored in 
a database; 

based on the comparison, identifying a trojan application on the network. 

32. A method of examining a network, comprising: 
sending packets to a network; 

receiving responsive packets from the network; 
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comparing information in the responsive packets to information stored in 
a database; 

based on the comparison, identifying unauthorized software use on the 
network. 

5 

33 . A method of examining a network, comprising: 
sending packets to a network; 

receiving responsive packets from the network; 

comparing information in the responsive packets to information stored in 
10 a database; 

based on the comparison, inferring an unknown vulnerability. 

34. A method of examining a network, comprising: 
sending packets to a network; 

1 5 receiving responsive packets from the network; 

comparing information in the responsive packets to information stored in 
a database; 

based on the comparison, identifying a security policy violation. 

20 
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35. A system for examining a network, comprising: 
a database including a set of reflex signatures; 
a packet generator; 

a comparison unit in communication with the packet generator and the 
database; 

wherein the packet generator is designed to generate and transmit a 
plurality of test packets to the network; 

wherein the comparison unit is designed to receive responsive packets 
from the network and to compare responsive packet information with the reflex 
signatures. 

36. The system of claim 35, wherein the comparison unit is further designed 
to identify a vulnerability in the network based on its comparison of packet 
information with reflex signatures. 

37. The system of claim 35, wherein the comparison unit is further designed 
to identify an operating system type, version, and patch level and a service type, 
version, and patch level of a host on the network. 
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38. The system of claim 35, wherein the comparison unit is designed to 
provide information to the packet generator, and wherein the packet generator is 
designed to use the information to selectively generate packets. 

5 39. A computer readable medium, having instructions stored therein, which, 

when executed by a computer, causes the computer to perform the steps of: 

identifying an operating system of a remote host, including aversion of the 
operating system; 

identifying a service on the port and a service of the remote host, including 
10 a version of the service; and 

identifying a vulnerability of the network based on information obtained 
from the steps of identifying an operating system and identifying a service. 

40. The computer readable medium of claim 39, wherein: 
15 the instructions for identifying an operating system further include 

instructions for identifying a patch level of the operating system; and 

the instructions for identifying a service further include instructions for 
identifying a patch level of the service. 

20 
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4 1 . The computer readable medium of claim 3 9, wherein: 

the step of identifying an operating system includes sending a first set of 
packets to the remote host and receiving a second set of packets from the remote 
host in response to said first set of packets; 

the step of identifying a service includes sending a third set of packets to 
the remote host and receiving a fourth set of packets from the remote host in 
response to said third set of packets, wherein information contained in said third 
set of packets is based on information received in said second set of packets; 

the step of identifying a vulnerability includes comparing information 
contained in the second sequence of packets and the fourth sequence of packets 
to information in a database. 

42. A method for use by a host on a network, comprising: 
receiving a set of selected packets from remote equipment; 
automatically sending a second set of packets to said remote equipment, 

which packets include information that enables the remote equipment to identify 
a vulnerability on the network. 

43 . A method for use by a host on a network, comprising: 
receiving a first set of packets from remote equipment; 
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automatically sending a second set of packets to said remote equipment; 

receiving a third set of packets from the remote equipment; 

automatically sending a fourth set of packets to the remote equipment; 

receiving a fifth set of packets from the remote equipment; 

automatically sending a sixth set of packets from the remote equipment; 

receiving a seventh set of packets from the remote equipment; 

automatically sending an eighth set of packets from the remote equipment; 

receiving a ninth set of packets from the remote equipment; 

automatically sending a tenth set of packets from the remote equipment; 

wherein said second, fourth, and sixth sets of packets include information 
that enables the remote equipment to identify an operating system on the network, 
including a version and a patch level; 

wherein said eighth and tenth sets of packets include information that 
enables the remote equipment to identify a service, including a version and a patch 
level. 
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ABSTRACT 

A system and method in accordance with the invention reliably and non- 
intrusively identifies various conditions of a network. In particular, an 
embodiment of the invention can identify an operating system, including version 
5 and patch level, and a service, including version and patch level, of a remote host 

on the network. Using this information, an embodiment of the invention can then 
reliably identify a vulnerability condition of the network. In some embodiments, 
the operating system and service information can be used to identify a trojan 
application, unlicensed software use, security policy violations, or even infer 
10 vulnerabilities that are yet unknown. 
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Title 37. Code of Federal Regulations. §1.56 

SECTION 1.56. DUTY TO DISCLOSE INFORMATION 
MATERIAL TO PATENTABILITY 



(a) A patent by its very nature is affected with a public 
interest. The public interest is best served, and the most 
effective patent examination occurs when, at the time an 
application is being examined, the Office is aware of and 
evaluates the teachings of ail information material to 
patentability. Each individual associated with the filing and 
prosecution of a patent application has a duty of candor and 
good faith in dealing with the Office, which includes a duty 
to disclose to the Office all information blown to that 
individual to be material to patentability as defined in this 
section. The duty to disclose information exists with respect 
to each pending claim until the claim is cancelled or 
withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a 
claim that is cancel led or withdrawn from consideration need 
not be submitted if the information is not material to the 
patentability of any claim remaining under consideration in 
the applicati on. There is no duty to subm it information which 
is not material to the patentability of any existing claim. The 
duty to disclose all wforrnatton known to be material to 
patentability is deemed to be satisfied if all information 
known to be material to patentability of any claim Issued in 
a patent was cited by the Office or submitted to the Office in 
the manner prescribed by §§l.97(b)-(d) and 1 ,98 * However, 
no patent will be granted on an application in connection with 
which fraud on the Office was practiced or attempted or the 
duty of disclosure was vioJated through bad faith or 
intentional misconduct. The Office encourages applicants to 
carefully examine: 

(1) prior art cited in search reports of a foreign patent 
office in a counterpart application, and 

(2) the closest information over which individuals 
associated with the filing or prosecution of a patent 
application believe any pending claim patentably 
defines, to make sure that any material information 
contained therein is disclosed to the Office, 

(b) Under this section, information is material to patentability 
when it is not cumulative to information already of record or 
being made of record in the application, and 



( 1 ) It establishes, by itself or in combination with other 
information, a prima facie case of unpatentability of a 
claim; or 

(2) It refutes, or is inconsistent with, a position the 
applicant takes ia* 

(i) Opposing an argument of unpatentability relied 
on by the Office; or 

(ii) Asserting an argument of patentability, 

A prima facie case of unpatentability is established when the 
information compels a conclusion that a claim is unpatentable 
under the preponderance of evidence, burden-of-proof 
standard, giving each term in the claim its broadest 
reasonable construction consistent with the specification* and 
before any consideration is given to evidence which may be 
submitted in an attempt to establish a contrary conclusion of 
patentability, 

(c) Individuals associated with the filing or prosecution of a 
patent application within the meaning of mis section are: 

( 1 ) £aeh inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes 
the application; and 

(3} Every other person who is substantively involved in 
the preparation or prosecution of the application and 
who is associated with the inventor, with the assignee or 
with anyone to whom there is an obligation to assign the 
application, 

(d) Individuals other than the attorney, agent or inventor may 
comply with this section by disclosing information to the 
attorney, agent, or inventor. 



* §§l,97(bH d > and ^8 re* 3 * 6 to tne OHung and manner in 
which information is to be submitted to the Office. 
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